摘 要: 在深入研究OSEK/VDX网络管理规范的基础上，提出一种针对OSEK直接网络管理的测试方法。根据OSEK NM规范设计直接网络管理测试架构以及测试方案,定义测试报文的数据结构。最后以CANoe总线分析测试软件为基础搭建测试平台,以OSEK直接网络管理的睡眠过程为例进行一致性测试。测试结果表明，该方法能有效地检测OSEK直接网络管理功能与OSEK NM规范的一致性。
关键词: OSEK/VDX网络管理； 一致性测试； CAN总线； CANoe
随着近年汽车产业的快速发展，电子产品广泛应用于汽车控制，如发动机控制系统、转向系统、制动系统等装置中都采用电子控制单元ECU(Electronic Control Unit)[1]。一些高档的轿车大约有70个ECU，ECU之间传递的信息超过2500条[2]。为了使ECU之间实现信息共享，诞生了在汽车控制系统中应用的互联网络，即车载网络。随着汽车中电子单元的增加，网络越来越复杂，ECU在通信时，可能由于其他节点未上线或出现故障而造成信息丢失，所以需要专门的网络管理组件对车载网络进行管理，以达到车载网络信息传输准确性、安全性的目的。
OSEK/VDX (Open Systems and the Corresponding Interfaces for Automotive Electronics/Vehicle Distributed eXecutive) 是欧洲主要的汽车厂商和研究机构联合提出的一种基于汽车电子开放式系统及其接口的软件标准。鉴于汽车网络的安全性和可靠性，OSEK/VDX中的网络管理NM(Network Management)规范提供了标准的管理策略，通过接口和服务来实现汽车网络中ECU节点的监控和管理[3]。OSEK/VDX规范对网络管理提出直接网络管理和间接网络管理两种实现机制。
OSEK/VDX规范是通过自然语言和图表形式进行描述的，程序开发人员在根据规范编写应用程序时，可能因为对规范的不同理解、编写代码时的失误等原因，导致应用程序与规范的不一致。对于安全性有极高要求的汽车电子系统而言，这种现象是不允许的。因此，有必要通过一致性测试来判断开发的应用程序是否符合预定规范。近年来，学术界对OSEK OS（OSEK Operation System）的一致性测试方法提出了一些解决方案。参考文献[4]提出了一种OSEK OS服务调用规范的一致性测试方法，参考文献[5]设计了一种OSEK OS一致性测试用例生成的方法，但是很少对OSEK NM的一致性测试做相应研究。
本文在深入研究OSEK网络管理规范的基础上提出了一种OSEK NM一致性测试方法，设计出一种基于直接网络管理功能的测试架构，并定义了测试方案、测试报文的数据结构和测试流程。
1 OSEK直接网络管理基本原理
在OSEK NM规范中，直接网络管理是一种自组织形式网络管理。网络中节点之间没有主从之分，每个节点都被网络中其他的节点监控，同时该节点也监控网络中的其他节点。直接网络管理通过逻辑环对车载网络进行管理与监控，如图1所示为直接网络管理逻辑环的体系结构。连接在总线上的A、B、C 3个节点都拥有自己唯一的网络管理身份标识ID,且IDA<IDB<IDC，根据ID的大小，以A→B→C→A的顺序传输特定的网络管理报文，形成一个虚拟逻辑环。在逻辑环中连接的所有节点按照逻辑环规定的方向发送特定的网络管理报文，实现直接网络管理功能。
图2所示为直接网络管理的状态模型。通过网络管理服务的调用和网络通信状况的改变，引起网络管理状态的迁移，如调用StartNM()服务可启动网络管理功能，使节点的状态从NMOff转为NMOn。
在直接网络管理中，为了满足通信和网络管理的需要，网络管理协议数据单元NMPDU(NM Protocol Data Unit)包括地址域、控制域和数据域。图3是网络管理协议数据单元的基本格式。其中，Source ID表示网络管理报文的源地址，即发送该网络管理报文的节点地址；
Destination ID表示网络管理报文的目标地址，即接收该网络管理报文的节点地址；Option Code表示操作码，用来设置网络管理报文的类型,其有Ring、Alive、LimpHome三种。 Data表示数据场，用于定义网络管理报文中的附加信息。
直接网络管理中各类型报文的作用：
(1)Ring报文：一个基本的监视报文，当网络状态为正常状态时，网络节点在定时器的触发下，根据节点ID的大小顺序地传送Ring报文。
(2)Alive报文：一个在非正常状态下的特殊报文，当一个新的节点要加入网络时，节点向网络中发送Alive报文。
(3)LimpHome报文：当接收/发送错误计数器超过其阈值或总线出现严重错误时，节点进入NMLimpHome状态，并周期地发送LimpHome报文。
2 OSEK NM的一致性测试方法
OSEK NM的一致性测试是一种功能性测试，在一致性测试中，测试者不必关心被测IUT（Implementation Under Test）内部的具体实现，只需关心其表现出来的外部行为[6-7]。
2.1 测试的体系结构
根据OSEK NM规范，将网络管理的测试体系结构分为两个部分，即被测系统及测试系统。
(1)被测系统，是IUT的载体，在测试系统中实现网络管理功能。
(2)测试系统，用来执行测试案例程序，该设备通过网络跟被测设备相互通信。
整个网络管理测试方案分为两个子块，即测试管理模块和辅助测试模块。测试管理模块由测试案例组成，在测试系统中运行；辅助测试模块作为被测系统的应用程序在被测设备中运行，用来配合测试管理模块完成网络管理功能的测试。在网络管理功能测试中，辅助测试模块起到两方面的作用，一方面用来响应测试系统的发来的请求，另一方面作为被测系统的应用程序，通过调用NM API函数，控制IUT的运行模式，并收集被测系统中IUT当前的状态信息，返回给测试系统。
测试管理模块和辅助测试模块之间的数据信息交换通过应用报文完成，该报文为测试管理协议数据单元（TM_PDU）。该方式下，2个测试模块之间的通信独立于底层网络管理通信协议，不影响网络管理功能。
在OSEK 直接网络管理中，网络出错处理机制是很重要的一部分。根据OSEK NM规范，OSEK NM可以处理一些常见的网络错误，如通信超时、BusOff等，所以本文在网络管理功能测试系统中增加了模拟和制造网络错误的模块。
综上所述，在直接网络管理的测试架构中，测试系统必须具备以下功能：
(1)测试系统必须具备网络管理功能，发送网络管理报文,并能模拟一个或多个网络管理节点的网络关系行为。
(2)测试系统能接受并分析NMPDU，判断被测系统中的IUT是否符合网络管理规范，即带有OSEK 直接网络管理功能。
(3)测试系统能够通过测试设备中一种特定的测试软件编程来控制相应的硬件设备，使总线出现特定的网络故障(如Vector公司的CAN总线干扰仪CANstress)。
2.2 测试方案和测试管理报文的定义
在直接网络管理模块正常工作时，ECU应用程序通过调用NM API接口函数来控制OSEK NM的相关动作，如功能开启、关闭及睡眠等。而在直接网络管理的测试过程中，整个测试系统必须能够模拟这一过程。为了实现这一功能，在测试系统与被测系统之间有两种类型的报文，即直接网络管理报文和测试管理报文。测试管理报文是测试管理模块和辅助测试模块之间的数据通道，使测试管理模块能够间接控制IUT，从而实现测试功能。图4所示为测试管理模块和辅助测试模块之间的两种通信模式。
测试系统用图4(a)所示的通信模式获取被测系统中
NM模块当前的状态以及配置信息，用图4(b)所示的通信模式控制辅助测试模块调用NM服务函数，图中虚线箭头表示根据需求服务的返回值可以选择性的传回测试系统。
400-878-1895
